Confirmed reads #3133
Open
Confirmed reads #3133
+1,544
−392
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
longer live. Also add commentary.
use the offset at commit / release (instead of the future) where possible
kim
commented
Sep 3, 2025
| return; | ||
| maybe_message = messages.recv(), if !closed => { | ||
| let Some(message) = maybe_message else { | ||
| // The message sender was dropped, even though no close |
There was a problem hiding this comment.
Unsure why the send_loop_terminates_when_unordered_closed started to fail with this patch, but the edge case seems legit.
Only thing to consider is whether the closed atomic should be re-checked when entering this branch.
| tracing::warn!( | ||
| identity = %self.id.identity, | ||
| connection_id = %self.id.connection_id, | ||
| confirmed_reads = self.config.confirmed_reads, |
There was a problem hiding this comment.
Note that a client with confirmed reads turned on has a somewhat higher risk to exceed the capacity.
It's not very likely, because CLIENT_CHANNEL_CAPACITY is such a large number, but is this warning loud enough?
| subscriptions.send_client_message(client, message, tx)?; | ||
| Ok::<Option<ExecutionMetrics>, anyhow::Error>(metrics) | ||
| }) | ||
| let (tx_offset_sender, tx_offset_receiver) = oneshot::channel(); |
There was a problem hiding this comment.
One-off queries are not really tested anywhere?
|
No idea what might be the matter on windows |
kim
force-pushed
the
kim/confirmed-reads
branch
from
9a0b8aa to
7011721
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
Implements subscribing to durable commits.
The setting works on a per-connection level, and essentially just delays sending transaction updates until the transaction is reported as durable by the database.
For connectionless SQL operations, the setting works per-request. No SQL syntax is provided by this patch to toggle the configuration.
After some deliberation, I opted to obtain the offset when a transaction commits (as opposed to when it starts). This creates some mild inconvenience, because we prevent the transaction from committing until the corresponding subscription updates are enqueued.
The strategy is, however, more correct should we ever support weaker isolation levels, and it is easier to document.
Follow-ups include:
SET synchronous_commit = ONor something)API and ABI breaking changes
Not breaking, but adds a parameter to the subscribe and sql endpoints.
Expected complexity level and risk
4
To the author's understanding, ordering of outbound messages is not changed by this patch, even if there are messages that don't have a transaction offset (such as error messages). I.e. while waiting for the transaction offset of a message to become durable, no message enqueued after that message will be delivered. This may not be desirable in some cases.
The patch may contain concurrency bugs, e.g. awaiting futures that may never resolve.
Testing
module_subscription_actormoduleClientConnectionReceiverIt would be desirable to also have integration-level tests, but I'm currently unsure how to write those without being able to control if and when the database reports an offset as durable.